REMARKS 



The above amendment and these remarks are responsive t 
the Office Communication of Examiner Victor D. Lesniewski, 
mailed 25 Nov 2005, and designated as Final. 

Claims 1-5, 8-14, 18-25, 29-30, 34-41, 43, and 45 -53 
are in the case, none as yet allowed. 



35 U.S.C. 103 



Claims 1-5, 8-14, 22, 24, 25, 29, 30, 34-37, 39, 41, 
43, 45, 47-50, 52, and 53 have been rejected under 35 U.S.C 
103(a) over Lucovsky (U.S. Patent 6,868,450) in view of 
Jackowski et al. (U.S. Patent 6,141,686, hereinafter 
Jackowski) . 



Applicants traverse, and argue that the Examiner has 
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not established a prima facie case of obviousness, which 
requires that the Examiner provide: 

1 . one or more references 

2. that were available to the inventor and 

3 . that teach 

4. a suggestion to combine or modify the references, 

5. the combination or modification of which would 
appear to be sufficient to have made the claimed 
invention obvious to one of ordinary skill in the 
art . 

The fourth element of the prima facie case, the 
suggestion to combine, must come from the prior art. It is 
insufficient to establish obviousness that the separate 
elements of the invention existed in the prior art, absent 
some teaching or suggestion, in the prior art, to combine 
the elements. [See Arkie Lures, Inc. v. Gene Larew Tackle, 
Inc., 43 USPQ 2d 1294 (Fed. Cir. 1997)]. 

That a claimed invention may employ known principles 
does not itself establish that the invention would have been 
obvious, particularly where those principles are employed to 
deal with different problems. The Examiner must consider 
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the claim as a whole, and not piece together the claimed 
invention using the claims as a guide. The Federal Circuit 
has stated: " [o] ne cannot use hindsight reconstruction to 
pick and choose among isolated disclosures in the prior art 
to deprecate the claimed invention. [See In re Fritch, 23 
USPQ 2d 1780, 1784 (Fed. Cir. 1992)]. 

Applicants argue that the combinations presented under 
35 U.S.C. 103 by the Examiner with respect to the claims in 
the case (rejections under both paragraphs 10 and 16) 
represent hindsight reconstruction of known principles 
dealing with different problems, pieced together using 
applicant's claims as a guide. 

In the present invention, IP packet filtering occurs in 
an operating system kernel implementation of, for example, 
the TCP/IP protocol suite. Access rules are expressed as 
filters referencing system kernel data; for outbound 
processing, source application indicia is determined; for 
inbound packet processing, a look-ahead function is executed 
to determine target application indicia; and responsive to 
the source or target application indicia, filter processing 
is executed. 
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In their previous amendment, applicants provide a 
detailed description of the Lucovsky reference and its 
distinctions with respect to the claims of the current 
application . 

With respect to claims 1, 10, 22, 25, 30, 34, 36, 37, 
39, 41, 43, 45, 48, 49, and 53, in the present Office 
Action, paragraph 12, the Examiner states: 

u . . .Lucovsky did not explicitly state. . ." 

and then continues the sentence to quote the 3rd clause of 
claim 1 , as follows : 

"...a look-ahead function being executed within a 
protocol stack including an IP layer, a transport 
layer, a sockets layer, and an application layer and 
which, for said inbound packet, said IP layer provides 
to said transport layer said inbound packet and 
receives back from said transport layer indicia, 
provided to said transport layer by said sockets layer, 
identifying the application layer application to which 
said packet would have been delivered." 
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The Examiner continues by referring to Jackowski, as 
follows : 

"However, Jackowski does explicitly disclose this 
feature as his system uses an extensible service 
provider within the stack to identify high-level 
applications . " [Emphasis added.] 

Apparently the antecedent of "this feature" is the 
material quoted above from the 3rd clause of claim 1. 

Applicants traverse the conclusion of the Examiner 
represented by the phrase "within the stack" in the above 
quoted material from paragraph 12. The Examiner is using 
the term "the stack" differently than in the present 
application. In applicant's claim, the phrase used is "the 
protocol stack", clearly referring to the following stack 
definition : 

"...a protocol stack including an IP layer, a transport 
layer, a sockets layer, and an application layer..." 
[Claim 1] . 

These layers are characteristic of a TCP/IP protocol stack, 



END920010019US1 



44 of 52 



S/N 09/919,185 



and in applicant' invention clearly refer to code that 
implements a suite of protocols, like those of the TCP/IP 
protocol, within the protocol stack. Jackowski just as 
clearly does not do anything "within the stack" in the same 
sense. See, for example, Jackowski ' s Figures 4, 5 and 10 
wherein Jackowski ' s "extensible service provider" is quite 
clearly positioned with respect to the TCP/IP stack and also 
quite clearly outside of it. 

There are implications to implementing a suite of 
protocols "within" the protocol stack that Jackowski does 
not address, as is discussed below. 

The Examiner then states : 

"It would have been obvious... to modify the system of 
Lucovsky. . . to which said packet would have been 
delivered as provided by Jackowski." [Office Action, 
paragraph 12.] 

Applicants traverse. The Jackowski function runs above 
the protocol (TCP/IP) stack. Thus, the above quoted 
sentence is not technically accurate. 
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Applicant's invention does IP packet filtering; that 
is, permitting and denying packets. It integrates 
traditional IP packet filtering and IP packet filtering 
based on non-IP packet attributes. It does not do 
prioritization, nor frequency counts - to which the 
Jackowski reference is directed. Basically, Jackowski does 
not do IP packet filtering, and what Jackowski does do is 
not done within the protocol stack defined in applicant's 
claims . 

With respect to claims 1, 10, 22, 24, 29, 34, 36, 37, 
39, 41, 43, 45, 47, 49, 50, and 52, in paragraph 13 of the 
Office Action, the Examiner states: 

"Again, the combination satisfies the need for a system 
that prioritizes network traffic based on high-level 
applications and users rather than..." 

Applicants traverse. Jackowski adds nothing to the 
combination cited with respect to these claims ' inasmuch as 
Jackowski does not filter, and what it does do does not run 
as part of the protocol stack. 

With respect to claims 1, 10, 22, 25, 30, 34, 36, 37, 
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39, 41, 43, 45, 48, 49, and 53, in paragraph 14 of the 
Office Action, the Examiner states: 

"In one instance Lucovsky discusses values that 
uniquely identify each process. See column 5, lines 
18-24 . " 

Lucovsky is right. But the Examiner states: 

"Lucovsky does not explicitly state marking a packet as 
non-deliverable. However, taking some action on a 
packet before passing it on for further filtering is 
well known in the art and Lucovsky has disclosed a 
variety of features that could be used for such an 
action. " 

Applicants traverse. The Lucovsky triplet is a well known 
logical consequence of the TCP/IP stack design and is not 
"taking some action on a packet before passing it on...", as 
the Examiner asserts. The Examiner then states: 

"For example, a packet could be marked as non- 
deliverable before being passed to the sockets layer if 
its data does not correctly identify a certain value of 
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at certain process." [Strikethru added.] 



That is true, but irrelevant, because that is not what 
applicants are claiming. The third clause of claim 1, for 
example, makes it clear that this marking is part of the 
look-ahead function, and that is not taught by Lucovsky. 

Applicants urge, therefore, that 1-5, 8-14, 22, 24, 25, 
29, 30, 34-37, 39, 41, 43, 45, 47-50, 52, and 53 be allowed. 



Claims 18-21, 23, 38, 40, 46, and 51 have been rejected 
under 35 U.S.C. 103(a) over Lucovsky in view of Jackowski, 
as applied above, further in view of Fiveash et al . (U.S. 
Patent 6,076,168, hereinafter Fiveash). 

With respect to claims 18-21, 23, 38, 40, 46, and 51, 
these claims relate to the advantage of being able to 
combine traditional IP filtering with non-packet attribute 
filtering. Unlike Jackowski, there is no separation of 
'policy' and filters. Again, Jackowski runs outside of the 
protocol (TCP/IP) stack. 
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While Fiveash is related, generally, to filtering, 
Fiveash does not provide look-ahead processing. Further, 
filtering is done by Fiveash only with respect to IP packet 
data, and not non-IP packet data as required by the claims, 
and thus, in combination with Lucovsky, does not teach the 
claims as currently presented with limitations relating to 
filtering of non-IP data and look-ahead processing. Because 
applicants can filter on non-IP packets, then that filtering 
can be applied to various kinds of IP tunnels. 

The Examiner uses the phrase 'may access a network' . 
It is clear that applicant's invention works for all inbound 
and outbound IP traffic on any system on which it is 
implemented. So applicant's invention is not just about 
access of a network. 

With respect to claims 18, 23, 38, 40, 46, and 51, the 
Examiner states, at paragraph 19 of the Office Action: 

"It would have been obvious to... modify the 
combination of Lucovsky and Jackowski by adding the 
ability to provide filter statements syntax as provided 
by Fiveash." 
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Applicants traverse. It makes more sense to say 'modify 
Lucovsky by adding the ability to filter. . . ' . That is, 
Jackowski is positioned at a completely different place than 
Lucovsky and Fiveash. Jackowski 's solution is above the 
TCP/IP stack. Hense, it would be unnatural and non-obvious 
to combine it with either Lucovsky or Fiveash. 

Concerning the obviousness of combining Lucovsky and 
Fiveash, Lucovsky 7 s approach was a way to use 'process 
attributes' to do some packet traffic control ('pass to the 
network and 'can pass to the process') precisely without 
changing or impacting IP filtering. (This was probably 
motivated by the fact that the Locovsky implementation did 
not have access to the TCP/IP stack and IP filtering 
implmentations . ) That is, Lucovsky avoids IP filtering, and 
hence has to build mechanisms like his 'system call trap 
handler' to make up for this lack, and use that to acquire 
the process attributes. 

In contrast, the present invention completely 
integrates non-IP packet attributes with IP filtering, both 
in the filtering language (expression) and execution (within 
the TCP/IP protocol stack) . This is not obvious when 
Fiveash is combined with Lucovsky because Fiveash uses 
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classic IP packet filtering using only IP packet attributes 
and Lucovsky uses a very different means of acquiring 
process attributes. 

Applicants, therefore, urge that the rejections under 
35 U.S.C. 103 be withdrawn, and that claims 18-21, 23, 38, 
40, 46, and 51 be allowed. 



SUMMARY AND CONCLUSION 

Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-5, 8-14, 18-25, 
29-30, 34-41, 43, and 45 -53. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
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can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary. 



Date: 2 5 February 2 006 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381-1341 

Phone: (276) 238-1972 

Fax: (276) 238-1545 

Correspondence Address: 

IBM Corporation 

Intellectual Property Law (Dept. 917, Bldg. 006-1) 
3 605 Highway 52 North 
Rochester, MN 55901-7829 



Sincerely, 



Edward B . Boden 



By 




ShelleW M iBeckstrand 
Reg. No. 24,886 
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